Project designers, such as software developers, hardware designers, etc., use design environments that include source control features. Source control provides a mechanism by which a designer or developer submits changes to portions of a project, such as source code, design code, media/multi-media objects, etc., and the changes may be “committed” to a central repository (e.g., added to the repository as the latest changes to that part of the source code) for the project upon successful completion of a build. A build may include performing compilation of code, unit/baseline tests, and/or the like, that are used to determine if errors or incompatibilities are present in the changes that would adversely affect the project. This type of source control acts as a gated check-in mechanism.
A build queue for these build requests is often used to govern the gated check-in decision. When a build request is submitted, it is placed in the build queue for processing of a build for the new or changed portions of the project. In larger projects, multiple build requests may be pending in the build queue waiting for verification of the build request at the head of the build queue to be performed. Upon completion of the build request at the head of the build queue, the next build request in the build queue is processed while the build requests below it remain pending, and so on. In such cases, a build request near the bottom of the build queue must wait for each build request above it before it is processed.